Fast and reliable wireless communication

ABSTRACT

A communication system that provides fast and reliable communications. The system is suitable for use in connection with wireless computing devices in which transmission errors may occur because of channel conditions, such as interference. Channel conditions causing transmission errors may be bursty and transient such that the errors temporarily overwhelm an error control code. By combining data received for multiple transmission attempts of a packet that fail error checking or that pass error checking with low reliability, a reliable representation of the packet may be quickly constructed. Though, combining may be omitted when a transmission attempt is received that passes error checking with high reliability.

This application is a continuation application of copending U.S. patentapplication Ser. No. 12/721,911, filed in the U.S. Patent and TrademarkOffice on Mar. 11, 2010.

BACKGROUND

As computers have grown into important tools that people use in allaspects of their business and personal lives, there has been anincreased demand from computer users to have full use of their computersregardless of location. To enable mobile computer use, computersfrequently are equipped for wireless communications so that computerusers can access information and services when away from their homes oroffices. Though, for these functions to be truly useful, it is desirablefor wireless communication to be fast and reliable.

To improve the speed and reliability of wireless communications, errorcontrol codes are known. Employing an error control code allows areceiving device to determine whether a packet of information has beenreceived with an error. Errors occur, for example, if noise in thecommunication channel causes the receiving device to incorrectlyclassify a received signal as representing a pattern of bits differentthan the pattern of bits that was sent by a transmitting device.

Depending on the characteristics of the error control code, thereceiving device, in addition to simply detecting an error, may also beable to determine the nature of the error and correct for it. Some errorcontrol codes can correct for multiple errors, with the number of errorsthat can be corrected being dependent on characteristics of the code.Though, regardless of the characteristics of the error control code,there is a limit on the number of errors that can be corrected.Accordingly, communication protocols account for the possibility that apacket will be received with more errors than can be corrected or willnot be received at all.

Some form of feedback between the receiving device and the transmittingdevice allows the transmitting device to recognize situations in which apacket was not received, which can trigger another attempt to transmitthe packet. When a packet is properly received, the receiving device maysend an acknowledgement message, sometimes called an ACK. When moreerrors than can be corrected occur in a packet, the receiving device maysend a reply to the transmitting device, indicating that the packet wasnot received correctly. Such a reply is sometimes called a negativeacknowledgement message, or a NAK.

Though, devices operating according to different protocols may signalreceipt of a packet or occurrence of errors in a received packet indifferent ways. For example, in some protocols, a receiving device maynot send any NAK when a packet is received with errors. Rather, it willsend an ACK to indicate receipt of a packet with no errors or, when anerror correcting code is used, receipt of a packet with a number oferrors that could be corrected. The transmitting device will infer, ifno ACK is received within a limited time, that a transmitted packet wasnot properly received.

Regardless of how the transmitting device determines that a packet wasnot received correctly, the transmitting device may respond to such adetermination by retransmitting the packet until it receives an ACK orreaches a limit on the number of transmission attempts set by a protocolused by the device.

The ability to detect and correct for errors in received packets canimprove the speed and reliability of communications because it avoidsthe need to retransmit a packet. Though, there are tradeoffs inselecting a desirable error control code. A stronger error control codethat can correct for more errors requires that packets contain more bitsto send the same amount of information than would be required to sendthe same packet using a weaker code that can correct for fewer errors.As a result, though a stronger code reduces the number of instances inwhich a packet has to be retransmitted, this benefit is offset by therequirement for more bits per packet if a stronger code is used. Adesigner of a communication system may select a strength of an errorcontrol code that balances both the positive and negative impacts ontransmission speed to provide, on average, improved performance.

In some instances, a better balance can be achieved using nested errorcodes. Codes are nested by applying a first error control code to bitsto be communicated in a packet. A second code may then be applied to thebits as modified using the first code. Further codes can be appliedsequentially in this fashion to provide a desired overall code strength.For example, it is known to first apply a cyclic redundancy check,sometimes called CRC, to bits to be transmitted. The CRC is a valueselected so that when the CRC is combined in a mathematical operationwith other bits in the packet, a known result occurs. If upon receipt,the known result does not occur when that mathematical operation isperformed, it can be inferred that an error occurred such that the bitsreceived do not match the bits transmitted. For example, the CRC may bea value that, when added with words formed by grouping the bits in thepacket, produces a sum of zero. If, upon receipt, when the CRC iscombined with other bits in the packet, the words do not sum to zero, itcan be inferred that an error occurred.

A second error control code may be applied to the bits of the packetwith the CRC. Forward error correction, or FEC, is an example of such acode. FEC associates each group of bits in a packet to be transmitted tomultiple possible similar bit patterns. Even if errors occur intransmission of the packet that change how the receiving device detectsthe bits of the packet, it is most likely that the receiver will detectone of the similar bit patterns. If so, the receiver can still associatethat bit pattern with the group of bits that was transmitted.

SUMMARY

Improved communication is provided by combined processing of multiplereceived transmission attempts of a packet, including those that passerror checking with low reliability. In some embodiments, an inner errorcontrol code may be used to determine whether a received transmissionattempt passes error checking. Information gleaned based on applying anouter error control code may be used to assess reliability. Receivedtransmission attempts may be selected for combined processing based onindications of whether received transmission attempts pass errorchecking and the reliability of the result.

If a received transmission attempt passes error checking with areliability above a threshold, the data in that packet may be passed onto higher level networking components in a computing device. Conversely,if a received transmission attempt of the packet does not pass errorchecking, or passes with a reliability below a threshold, thattransmission attempt may be combined with one or more previously orsubsequently received transmission attempts for the same packet. Anynumber of transmission attempts of the packet may be combined in thisway to determine a value for each bit in the packet that is regarded asreliable.

In one aspect, the invention relates to a method of operating acomputing device to receive packets and provide received packets to anetwork component. The method includes with a network interface circuit,receiving a first packet. Error checking is performed on the firstpacket. The error checking is adapted to identify whether a packet thatpasses error checking and is reliable, a packet that passes errorchecking and is unreliable or a packet that fails error checking. Whenthe error checking indicates that the first packet has passed errorchecking, at least a portion of the first packet is provided to thenetwork component. When the error checking indicates that the firstpacket passes error checking and is unreliable or fails error checking,at least one second received packet is combined with the first packet toform a combined packet. At least a portion of the combined packet isprovided to the network component.

In another aspect, the invention relates to a wireless receiving devicethat has a wireless network interface for receiving transmissionattempts of a packet. The device also includes an error checkingcomponent that applies nested error control codes comprising at least aninner error control code and an outer error control code to a receivedtransmission attempt of a packet to determine whether the receivedtransmission attempt of the packet passes or fails based on the innererror control code and a degree of reliability based on the inner errorcontrol code. The device further includes computer storage medium forstoring information representing attempts to transmit the packet. Anetwork stack can provide data from received packets to applicationlevel components executing on the wireless receiving device. A packetanalyzer can, in response to a received transmission attempt of a packetreceived by the wireless network interface, selectively store thereceived transmission attempt in the computer storage medium or providepacket data to the network stack. The packet analyzer selectivelyprovides packets to the network stack by: when the received transmissionattempt of the packet is determined by the error checking component topass with a degree of reliability above a first threshold, providing thereceived transmission attempt of the packet to the network stack. Whenthe received transmission attempt of the packet is determined by theerror checking component to pass with a degree of reliability below thethreshold and when the received transmission attempt of the packet isdetermined by the error checking component to fail, different processingmay be performed. That processing may include, when received informationrepresenting a prior transmission attempt of the packet is stored in thecomputer storage medium, forming a combined packet based on the receivedtransmission attempt of the packet and the stored received informationand selectively providing the combined packet to the network stack whenthe combined packet passes based on the outer error checking code andhas a degree of reliability based on the inner error correcting codeabove a second threshold. Though, when received information representinga prior attempt to transmit the received packet is not stored in thecomputer storage medium, selectively providing includes storing anindication of the received transmission attempt of the packet in thecomputer storage medium.

In yet a further aspect, the invention relates to at least onenon-transitory computer storage medium comprising computer-executableinstructions that, when executed, perform a method that includesreceiving error checking information on a first transmission attempt ofa packet. The error checking information identifies whether the firsttransmission attempt of the packet passed error checking and isreliable, passed error checking and is unreliable or failed errorchecking. When the error checking indicates that the first transmissionattempt of the packet has passed error checking, at least a portion ofthe first transmission attempt of the packet is provided to a networkstack. When the error checking indicates that the first transmissionattempt of the packet passed error checking and is unreliable or failederror checking, combining at least the first transmission attempt of thepacket and a second transmission attempt of the packet to form acombined packet, and providing at least a portion of the combined packetto the network stack.

The foregoing is a non-limiting summary of the invention, which isdefined by the attached claims.

BRIEF DESCRIPTION OF DRAWINGS

The accompanying drawings are not intended to be drawn to scale. In thedrawings, each identical or nearly identical component that isillustrated in various figures is represented by a like numeral. Forpurposes of clarity, not every component may be labeled in everydrawing. In the drawings:

FIG. 1A is a sketch of an environment in which embodiments of theinvention may operate;

FIG. 1B is a functional block diagram of a transmitting device of FIG.1A;

FIG. 1C is a functional block diagram of a receiving device of FIG. 1A;

FIG. 2 is a sketch depicting signal transmission parameters useful inunderstanding a forward error correction code that may be employed insome embodiments of the invention;

FIG. 3 is a sketch conceptually illustrating a received transmissionattempt of a packet;

FIG. 4 is a sketch of a data structure storing multiple receivedtransmission attempts of a packet according to some embodiments;

FIG. 5 is a functional block diagram of components for combiningportions of multiple transmission attempts of a packet;

FIG. 6 is a flow chart illustrating a method of processing multipletransmission attempts of a packet; and

FIG. 7 is a flow chart of a method of operating a transmitting deviceaccording to some embodiments of the invention.

DETAILED DESCRIPTION

The inventors have recognized and appreciated that a desirable tradeoffbetween speed and reliability of communication can be achieved bycombining information from multiple transmission attempts of a packet.The transmission attempts may include those that failed error checkingas well as those that passed error checking, but with low reliability.

FIG. 1A illustrates an environment in which embodiments of the inventionmay be employed. FIG. 1A illustrates two computing devices, computingdevice 110A and 110B. In this example, computing device 110A is actingas a transmitting device and computing device 110B is acting as areceiving device. Computing device 110A is attempting to transmit apacket of data wirelessly over channel 120 to computing device 110B.Though, it should be appreciated that, in many systems, devices will, atdifferent times, transmit and receive information. Thus, any device maybe a transmitting device, a receiving device or both. Though, forsimplicity of illustration, only transmission from computing device 110Athat are received at computing device 110B are described.

In the embodiment illustrated in FIG. 1A, computing devices 110A and110B are both portable electronic devices. In the specific example,computing devices 110A and 110B are both illustrated as laptopcomputers. However, it should be appreciated that computing devices 110Aand 110B may be any suitable computing devices, including fixed devices.As an example of a possible variation, one of computing device 110A or110B could be an access point for a wireless network.

Regardless of the nature of computing devices 110A and 110B, it may bedesirable for communications between computing devices 110A and 110B tooccur quickly and reliably. In accordance with some embodiments, adesirable balance of speed and reliability for a transmission fromcomputing device 110A to computing device 110B is achieved by combininginformation received at computing device 110B during multipletransmission attempts of the packet.

FIG. 1B illustrates components within computing device 110A that may beinvolved in transmission of a packet of data from computing device 110A.In some embodiments, the components within computing device 110Atransmitting a packet may be components as are known in the art. In someembodiments, a computing device using novel techniques to receivepackets may operate with a conventional device transmitting packets.

Though as described below, in some embodiments the components involvedin transmitting may be modified for improved transmission properties. Inembodiments in which the components in computing device 110Atransmitting a packet are components as are known in the art, thosecomponents may operate according to a known communication standard, suchas 802.11(b) or 802.11(g) or 802.11(n). In embodiments in which thecomponents are modified as described herein, those components maynonetheless be constructed using techniques as are known in the art.

In the example of FIG. 1B, application 130 generates data to betransmitted from computing device 110A to computing device 110B.Application 130 may be a software program executing, as is known in theart, on computing device 110A. However, the nature of application 130and the nature of data generated by application 130 for transmission tocomputing device 110B is not critical to the invention.

Regardless of the nature of application 130, the data generated byapplication 130 may be passed to a network component, here illustratedas network stack 132. Network stack 132 may be a network stack as iscontained in an operating system (not shown) on computing device 110A asis known in the art. Network stack 132 provides an interface betweenapplications, such as application 130, and other components withincomputing device 110A that manage transmission of data overcommunication channel 120.

Network stack 132 may process data generated by application 130 inaccordance with one or more protocol layers. For example, it is known inthe art to use a transmission control protocol (TCP) and an Internetprotocol (IP) in connection with transmission of information between twocomputing devices. Accordingly, network stack 132 may format datagenerated by application 130 in accordance with the TCP/IP protocols.This formatting may include adding packet headers or other overheadinformation used in routing data, generated by application 130, to anintended destination.

However, the specific formatting of information performed within networkstack 132 is not critical to the invention. The result of processingwithin network stack 132 may be a bit stream 134 representing a packetto be transmitted. Though denominated a bit stream, bit stream 134 mayinclude groups of bits representing data elements, such as bytes orwords. Accordingly, it should be appreciated that the specificformatting of data within bit stream 134 is not critical to theinvention.

In the example of FIG. 1B, bit stream 134 is applied to an encodingsegment 135. Within encoding segment 135, one or more error controlcodes are applied. In this example, nested error control codes are used.Though more than two error control codes may be nested, two areillustrated in FIG. 1, with a first error control code used as an innererror control code and a second error control code being used as anouter error control code. As a specific example, a cyclic redundancycheck (CRC) is an example of an inner nested error control code. Forwarderror correction (FEC) is used as an example of an outer errorcorrecting code.

Regardless of the specific error control codes applied, the output ofencoding segment 135 is applied to a transmitter for transmission overcommunication channel 120. In the example of FIG. 1B, the transmitter iscontained within a network interface card (NIC) 146. Accordingly, FIG.1B illustrates a transmit signal 144 output by encoding segment 135being applied to NIC 146. Though, it should be appreciated that thephysical components used for transmitting a packet may be incorporatedin any suitable hardware element and may be packaged in any suitableway.

Within encoding segment 135, one or more operations may be performed onbit stream 134 to prepare it for transmission. In the embodimentillustrated, encoding segment 135 includes components 140 and 142.

Component 140 is an example of a component that may apply an inner errorcontrol code. In this example, component 140 computes a cyclicredundancy check (CRC). The CRC may be computed in a known way. As oneexample, the CRC may be computed by adding bytes, words or other groupsof bits in bit stream 134. The sum may be expressed as a negative valueand appended to the encoded bit stream. As a result, when the bit streamis processed at receiving computing device 110B, if the same computationis performed on the received bits, including the CRC, the sum should bezero if no errors occurred during transmission. Though, the CRC may becomputed in any suitable way and, alternatively or additionally, othercodes that can detect or detect and correct errors may be used.

Regardless of how the CRC is computed, the bit stream 134 with the CRCis passed to component 142. Component 142 applies forward errorcorrection encoding to the bit stream. The encoded bit stream is thenpassed on for transmission.

In this example, component 142 encodes bit stream 134, including theCRC, as a stream of symbols. The encoding performed by component 142 mayincorporate redundancy into the representation of bit stream 134 thatenables a receiving device to detect and correct for errors. Forexample, component 142 may encode an input bit stream by mapping groupsof two bits in the bit stream into symbols, each of which is representedby four bits. The mapping between bits in the input bit stream andsymbols may be such that even if errors change one or more of the bitsin the symbol, it is possible to identify a likely bit pattern that wasencoded into the symbol.

Any suitable encoding scheme may be used by component 142. In theexample in which groups of two bits of an input bit stream are mapped tosymbols having four bits, there are two redundant bits in each symbol.Such an encoding is said to have a coding rate of one-half, indicatingthat half of the bits per symbol are used to convey information and halfare redundant and are included to allow for detection and correction oferrors.

Component 142 may use an encoding scheme that provides any suitablecoding rate. In some embodiments, component 142 may use the same codingrate for all transmission attempts of a packet. However, in someembodiments, component 142 may decrease the coding rate for subsequentretransmissions of a packet. The coding rate may be changed, forexample, by changing the mapping between groups of bits in the input bitstream and the symbols used to represent each group.

Though, it is not a requirement that component 142 incorporateredundancy into the encoding of a bit stream on a symbol-by-symbolbasis. As an example of one alternative, component 142 may insert one ormore redundant bits for each of multiple symbols generated by component142. Adding redundant bits in this fashion also lowers the coding rate,which increases the likelihood that a transmission attempt of a packetwill be reliably received. In embodiments, as described below, in whichthe coding rate is dynamically adjusted, component 142 may use anysuitable technique, whether now known or hereafter developed, to adjustthe coding rate. If the coding rate is adjusted, information in a packetheader, or communicated in any other suitable way to computing device110B, allows computing device 110B to identify and use the redundantbits to process a received transmission attempt.

FIG. 1C illustrates components that perform processing within computingdevice 110B upon receipt of a transmission attempt of a packet. In theexample of FIG. 1C, the packet is received by a receiver within anetwork interface card (NIC) 150. NIC 150 provides a received signal 152to a decoding segment 153. Decoding segment 153 may perform operationsthat are the inverse of those performed by encoding segment 135 torecover a bit stream 174. The recovered bit stream can then be providedto a network stack 176. Network stack 176 may direct the bit stream 174,representing a received packet, to an appropriate component withincomputing device 110B. In the embodiment illustrated, the destination ofthe packet is application 178, which may be an application as is knownin the art executing on computing device 110B. However, the destinationof a received packet within computing device 110B is not a limitation onthe invention.

Within decoding segment 153, the received signal 152 is passed tocomponents 154 and 156. These components successively apply errorcontrol codes in a nested fashion. In this example, the same errorcontrol codes used in encoding segment 135 are also applied in decodingsegment 153, but in the reverse order and in a complementary fashion.Rather than using the error control codes to encode information, theyare applied to decode the information that was encoded beforetransmission. Accordingly, received signal 152, representing atransmission attempt of a packet, is applied to component 154 thatapplies an FEC code to recover groups of bits from the received signal152. If no errors occurred in transmission of a packet attempt, or anyerrors that occurred could be corrected by the FEC code, the output ofcomponent 154 should contain recovered bits accurately representing bitstream 134 that was to be transmitted. Though, if the errors thatoccurred overwhelmed the FEC code, the recovered bit stream may not bean accurate representation of the packet that was transmitted.

The inner error control code may be used to determine whether therecovered bits accurately represent the transmitted bits. Though, insome scenarios, the inner error control code may also be overwhelmedsuch that, even if the inner code indicates that a transmission attemptof a packet was received with no errors, there may in fact be errors.

In the embodiment illustrated, CRC is used as the inner error controlcode. In this embodiment, the recovered bits output by component 154 areapplied to component 156 that performs a cyclic redundancy check.Component 156 may perform a cyclic redundancy check as is known in theart.

In a conventional receiving device, if the cyclical redundancy checkindicates that the decoded bit stream contains no errors, the bit streamis provided to a network stack, such as network stack 176. In responseto passing the CRC, the network interface hardware may also be triggeredto generate an ACK message to the sender. Conversely, if the cyclicredundancy check indicates that the transmission attempt of the packetwas received with one or more errors, even after processing within FECdecode component 154, the received transmission attempt may be discardedand a notification may be sent to a network interface component, such asNIC 150, to await receipt of a further transmission attempt and, in someprotocols, to send a NAK to prompt the sending device to retransmit thepacket.

However, in the embodiment illustrated in FIG. 1C, additional processingis performed to determine whether to send an ACK or a NAK, if receivingdevice 110B is communicating according to a protocol that uses a NAK. Inthe embodiment, illustrated, that additional processing is performedwithin packet analyzer 170. Accordingly, the results of the cyclicalredundancy check performed by component 156 are provided to a packetanalyzer 170. Packet analyzer 170 also receives the decoded bits 162. Inaddition, packet analyzer 170 receives information from FEC decodecomponent 154, indicating the reliability of the information receivedfor the transmission attempt.

Based on this information, packet analyzer 170 may determine that thebits received for the transmission attempt are a reliable representationof transmitted data and pass the decoded bits to network stack 176 asbit stream 174. In other scenarios, packet analyzer 170 may deem thedecoded bits to be unreliable and perform processing to improve thereliability of the bit stream and then provide a bit stream to networkstack 176. In yet other scenarios, packet analyzer 170 may determinethat it lacks adequate data to reliably provide data to network stack176. In that case, packet analyzer may store the decoded bits 162 forprocessing later in connection with subsequently received transmissionattempts of the packet.

Based on the disposition of the received transmission attempt, packetanalyzer 170 may trigger sending of an ACK or, in embodiments usingprotocols that include a NAK, sending of a NAK. An ACK may be sent ifdata is provided to network stack 176 as a result of a receivedtransmission attempt of a packet and a NAK may be sent if furtherprocessing, based on subsequently received transmission attempts, may beused to generate data to pass to stack 176.

In the embodiment illustrated, packet analyzer 170 determines, for eachreceived transmission attempt, whether it has sufficient information toreliably determine the contents of bit stream 174 to be provided tonetwork stack 176. Packet analyzer 170 may generate the reliableinformation by combining a received transmission attempt of a packetwith information representing a previously received transmission attemptof the packet. In this example, information characterizing a previouslyreceived transmission attempt may be stored in packet store 172. Inscenarios in which packet store 172 does not contain adequateinformation from prior transmission attempts to reliably determine thecontents of bit stream 174, packet analyzer 170 may store a receivedtransmission attempt in packet store 172 for use when a subsequenttransmission attempt of that packet is received.

In the embodiment illustrated, the processing in packet analyzer 170 isbased both on an indication of whether a received transmission attemptpasses error checking, as indicated by component 156, and a reliabilityof the received data as indicated by component 154. FIG. 2 illustratesan approach that may be used to determine reliability of received data.Though, it should be appreciated that FIG. 2 is illustrative rather thanlimiting, and any suitable technique for determining reliability ofreceived data may be used.

FIG. 2 depicts analog signal characteristics used to represent symbolsin channel 120. In the example illustrated the characteristics are showngenerally as C₁ and C₂. These analog characteristics, for example, maybe signal amplitude and signal phase or signal frequency and signalamplitude. However, the specific characteristics are not critical andany characteristics that can be modulated by NIC 146 and detected by NIC150 may be used. In the example illustrated, four regions M₁, M₂, M₃ andM₄ are illustrated. Each of these corresponds to a symbol representing aspecific pattern of bits. To transmit a bit pattern, NIC 146 generates asignal with characteristics corresponding to the pattern of bits.

In the embodiment illustrated, NIC 146 may transmit a signal withcharacteristics indicated to be at the center of one of the four regionsM₁, M₂, M₃ and M₄. Though, as the transmitted signal propagates throughchannel 120, noise may distort the signal characteristics. For thisreason, NIC 150 will associate any signal with characteristics anywherewithin a region to be associated with that region. Though, signalsreceived with characteristics further from the center of a regionindicate that there was likely more error introduced in channel 120 thanwhen signals are received with characteristics at or near the center ofthe region. FIG. 2 shows with an X the signal characteristics receivedand an error, ρ. That error can be taken as an indication of thereliability of the received data, with smaller values of ρ indicatingmore reliable data.

FIG. 2 illustrates an embodiment in which a measure of reliability isdetermined based on characteristics of a received analog signal, whichmay be provided by NIC 150. An analogous approach may also be based ondigital information in a received signal. A digital approach may bebased on a coding scheme in which there are redundant patterns of bitsused to represent a single symbol. For example, a symbol may berepresented by a bit pattern (0,0,0). Similar bit patterns may be unusedfor representing any transmitted symbol, but may be associated with thebit pattern (0,0,0). Bit patterns (0,0,1), (0,1,0) and (1,0,0) may allbe associated with the same symbol as the bit pattern (0,0,0). If any ofthe bit patterns (0,0,1), (0,1,0) and (1,0,0) is received, it is clearthat one or more errors occurred, even though the received bit patterncan be mapped to a transmitted symbol. The number of bits differentbetween the pattern detected and the pattern used to represent a symbolupon transmission may also be a measure of error. More generally, thecoding distance between a received bit pattern and nominal bit patternto represent a signal may be taken as a measure of error or, conversely,as a measure of the reliability of the data received.

FIG. 3 illustrates data that may be generated for a receivedtransmission attempt for a packet. Packet 310 is shown to consist of aseries of received symbols and associated reliability information. Here,the symbols are represented as S₁, S₂ . . . S_(N). The reliabilityassociated with each is indicated as ε₁₅, ε₂, . . . ε_(N). Thereliability values may be determined as the reciprocal of the error orin any other suitable way.

Regardless of the manner in which reliability information is generated,it may be used within packet analyzer 170 to determine subsequentprocessing steps for a received transmission attempt. In someembodiments, an overall reliability for a received transmission attemptfor a packet may be determined. This overall value may then be comparedto a threshold value or otherwise used to determine whether a receivedtransmission attempt is reliable. In some embodiments, the reliabilityvalues ε₁, ε₂, . . . ε_(N) associated with each of the symbols may beaggregated, such as by summing the reliability values, averaging thereliability values across all received symbols or counting the number ofsymbols for which an individual reliability value is below a threshold.The specific thresholds to determine reliability may be determined inany suitable way, and, for example, may be based on computation orempirical measurements.

Regardless of how reliability is determined for a received transmissionattempt, it may be used to determine whether a received transmissionattempt is sufficiently reliable to forward to network stack 176 or iffurther processing, in conjunction with previously received orsubsequently received transmission attempts for the same packet, iswarranted to improve reliability.

In the illustrated embodiment, a transmission attempt of a packet isforwarded to network stack 176 only if at least two criteria are met.That transmission attempt must pass error checking provided by all errorcontrol codes and must have a reliability above a threshold. Otherwise,the packet is routed for further processing to increase the reliabilityof data provided to network stack 176. The inventors have recognized andappreciated that some communication errors may occur in bursts such thatsufficient errors may occur for a transmission attempt that the errorsmay simultaneously overwhelm error control codes, such as FEC and CRC.Accordingly, even though CRC indicates that a transmission attempt wasaccurately decoded, the received transmission attempt may actuallycontain errors. Accordingly, conditioning processing of receivedtransmission attempts, even those that pass error checking, on thereliability of receipt improves communications.

Further processing on received transmission attempts may be based oninformation representing received transmission attempts stored in packetstore 172 (FIG. 1) in combination with a newly received transmissionattempt. FIG. 4 illustrates an example of data in packet store 172,representing previously received transmission attempts, in combinationwith a newly received transmission of a packet. As illustrated, packetanalyzer 170 may have access to data on multiple transmission attempts,here represented as data sets 410A . . . 410M, representing each of Mreceived transmission attempts. In the example illustrated, the data oneach transmission attempt includes values for each of N symbols that maybe part of the packet. Accordingly, each data set is shown to have Nportions, each representing a symbol and a reliability associated withthat symbol.

Reliable data representing a received packet may, in some scenarios, bederived by processing these data sets together. The data may beprocessed to select, on a symbol by symbol basis, reliable symbols thatcollectively form a combined packet. Though, any suitable processing maybe used to form a combined packet. In the embodiment illustrated, eachof the data sets 410A . . . 410M contains a value for each symbol in thepacket. One approach to forming a combined packet is to select, for eachsymbol in the received transmission attempts of the packet, thecorresponding symbol from the data sets 410A . . . 410M that is mostreliable. As an example, across the data sets 410A . . . 410M, there aremultiple possible values for the first symbol, indicated as S_(1A),S_(1B) . . . S_(1M). One of these values may be selected based on anassociated reliability, ε_(1B), ε_(1B) . . . ε_(1M), respectively, thatis highest. For example, if ε_(1B) is the highest reliability, S_(1B)may be selected as the first symbol. Other symbols in the combinedpacket may be similarly selected from the data structure illustrated inFIG. 4.

Though, any suitable approach may be used to combine data setsrepresenting multiple received transmission attempts. As an example, ofan alternative approach, symbols in the combined packet may be computed.FIG. 5 illustrates an embodiment in which an average of correspondingsymbols in the data sets 410A . . . 410M is computed and the average ofeach symbol is used as the corresponding symbol in the combined packet.The average may be computed as a weighted average, with each symbol in areceived transmission attempt being weighted by the reliability of thatsymbol.

FIG. 5 illustrates processing that may be performed in hardware orsoftware components. FIG. 5 illustrates the processing to compute onesymbol in a combined packet. The illustrated processing may be performedfor each symbol in the combined packet. As shown, corresponding symbolsS_(1A), S_(1B) . . . S_(1M) in each of M received transmission attemptsand the reliabilities ε_(1B), ε_(1B) . . . ε_(1M) associated with thosesymbols are taken as inputs. Each symbol is weighted by its reliabilityin multipliers 510A, 510B . . . 510M. The weighted symbol values aresummed in adder 520 and then normalized in a divider 530, which dividesby M.

Though, it should be appreciated that FIG. 5 is illustrative and notlimiting of approaches for forming a combined packet. For example, themost frequent symbol value may be selected or a symbol value may beselected in any other suitable way.

In conjunction with selecting a value for each symbol in a combinedpacket, a corresponding reliability may be determined. The reliabilitymay be computed in any suitable way. The reliability could, for example,be an average of the reliabilities associated with symbols combined intothe combined symbol. Though, the reliability may be computed orestimated based on the value of the selected symbol and the values ofthe corresponding symbols in the data sets representing receivedtransmission attempts and their associated reliabilities. Such a valuecould be computed as a conditional probability given multipleobservations. As one example, the following conditional probabilityequation could be used to represent the reliability of the combinedpacket:ε₁ =P(S ₁ |S _(1A) ,S _(1B) . . . S _(1M),ε_(1A),ε_(1B) . . .ε_(1M))  EQ. (1)

Such a conditional probability may be computed using techniques as areknown in the art. Though, a reliability of a combined packet may bedetermined in any other suitable way.

Regardless of how it is computed, the reliability of the combined packetmay be used to determine whether the combined packet is a reliablerepresentation of a packet such that the data in the combined packet isto be passed to network stack 176 or other network component for furtherprocessing. The combined packet may be deemed reliable when the computedreliability exceeds a threshold and/or the combined packet passes a CRCerror check.

If the combined packet is deemed reliable and is passed to network stack176, packet store 172 may be erased. In this way, packet store 172contains at any one time only data representing transmission attempts ofthe same packet.

FIG. 6 is a flow chart of a method of operating a receiving device, suchas computing device 110B (FIG. 1A), to from a combined packet. Themethod of FIG. 6 begins at block 610 where the receiving device receivesdata, representing a transmission attempt of a packet. That data may bereceived using hardware as is known in the art or in any other suitableway.

At block 612, an outer error control code may be applied to the datareceived at block 610. In the embodiment illustrated, the outer errorcontrol code is an FEC code. Accordingly, at block 612, FEC decoding isperformed. This decoding may be performed in hardware or softwareelements using techniques known in the art or in any other suitable way.

Following application of the outer most error control code, one or moreinner error control codes may be applied. In the embodiment illustratedin FIG. 6, two, nested error control codes are used. Accordingly, atblock 614 an inner error control code is applied. In this example, theinner error control code is a CRC code. Accordingly, at block 614, a CRCcomputation is performed.

At decision block 620, the process branches depending on the results ofthe CRC computation performed at block 614. If the computation performedat block 614 indicates that the data received at block 610 passes theCRC check, the process branches to decision block 622. At decision block622, the process again branches depending on whether the data receivedat block 610 has been deemed reliable. In some embodiments, data may bedeemed reliable based on the number and nature of errors detected byapplication of the FEC code. However, any suitable mechanism fordetermining reliability may be employed.

If the data is deemed reliable, the process branches to block 624. Atblock 624, cached data, representing previously received transmissionattempts of the same packet may be discarded. In the embodiment of FIG.1C, processing at block 624 may involve clearing packet store 172.

The process of FIG. 6 then proceeds to block 626 where the packet isnotified. As is known in the art, a received packet is “notified” whendata associated with the packet is stored in memory accessible tooperating system components that further process the packet and deliverit to a user mode component or application executing on a computingdevice and designated as the destination for the packet. Though itshould be appreciated that the results of processing at block 626 isthat the packet is available to the destination identified in thepacket, and any suitable mechanism for making the packet available forthe destination may be used.

Conversely, if the CRC check performed at block 614 fails, indicatingthat one or more errors exist in the received transmission attempt thatcould not be corrected by the FEC code, the process of FIG. 6 branchesfrom decision block 620 to other processing blocks in which failedpackets may be processed. In the example illustrated, processingbranches from decision block 620 to decision block 630. At decisionblock 630, a check may be performed to determine whether the reliabilitymetrics associated with the received packet are acceptable. Processingat decision block 630 may identify a received transmission attempt thatis so unreliable that it is not used in further processing. Accordingly,the processing at decision block 630 may involve comparing reliabilitymetrics generated as a result of FEC decoding to a threshold value thatis lower than the threshold applied at decision block 622.

If the received transmission attempt is determined to be unacceptablefor further processing, the data representing the received transmissionattempt may be discarded and the process may branch to block 632. Atblock 632, the receiving device may generate a NAK, indicating that thereceiving transmission attempt for the packet did not result in reliablereception. As in known protocols, sending a NAK at block 632 may triggerthe sending device to make a further attempt to transmit the packet.Accordingly, the process loops back from block 632 to block 610, wherefurther transmission attempts may be received.

Conversely, if processing at decision block 630 deems that the receiveddata representing a transmission attempt of a packet is acceptable foruse in further processing even if not sufficient to be passed on tonetwork components as a reliable representation of a received packet,the process may continue to block 640. At block 640, the data receivedat block, 610 may be added to a data set presenting receivedtransmission attempts of a packet.

At block 642, the data set representing transmission attempts of apacket may be combined. As described above, the attempts may be combinedon a symbol by symbol basis or may be applied on a bit by bit basis orin any other suitable way.

The combined packet produced at block 642 may then be further processedto determine whether it reliably represents the packet. This processingmay entail processing to determine both whether the combined packetappears to contain errors and whether the underlying data appearsreliable. In the embodiment illustrated in FIG. 6, this processingbegins at block 644 in which FEC decoding is performed on bits of thecombined packet. In this block, errors may be corrected as a result ofapplication of the FEC code. Additionally, a measure of the reliabilityof the decoding performed at block 644 may be generated. The decodingperformed at block 644 may use the same mechanisms as are used at block612 to correct errors and develop an indication of the reliability ofthe bits output as a result of FEC decoding.

At block 646, a CRC code may be applied to the bits output by FECdecoding at block 644. Processing at block 646 may use techniquessimilar to those performed at block 614. Though, processing at block 650may use any suitable techniques to determine whether the combined packetgenerated at block 642 appears to contain errors. The process of FIG. 6branches at decision block 650 depending on whether the error checkingblock 646 indicates errors in the combined packet. If the combinedpacket does not pass error checking based on the CRC code, the processbranches to block 632. At block 632, a NAK is sent and the process loopsback to block 610, where a further retransmission attempt may bereceived.

Conversely, if the combined packet passes error checking, the processmay branch from decision block 650 to decision block 660. At decisionblock 660, the process may again branch. Branching at decision block 660may be based on the reliability of the combined packet. In thisembodiment, the reliability of the combined packet may be based oninformation relating to the likelihood of errors in the received packetas determined by FEC decoding at block 644. However, any suitablemechanism may be used to determine whether the combined packet isreliable. If the combined packet both passes error checking and isdeemed to be reliable data, the process branches from decision block 660to block 626. At block 626, as described above, the packet is notifiedto a networking component that routes a received packet to itsdestination. However, when processing reaches block 626 through decisionblock 660, rather than the packet received at block 610 being notified,the combined packet, generated by processing at block 642, is notified.

The processing as illustrated in FIG. 6 may be repeated iteratively onsuccessive received transmission attempts. Though, there may be limitson the number of iterations performed. If the combined packet is notdeemed reliable, processing may branch from decision block 660 todecision block 670. At decision block 670 the process may again branch.Branching at decision block 670 is based on the number of receivedtransmission attempts that have been processed. If the number ofreceived transmission attempts is below a threshold, the process mayloop back through block 632 to block 610. Conversely, if the number ofiterations through the processing illustrated in FIG. 6 exceeds amaximum number of iterations, processing may terminate in an errorcondition. A determination of whether the number of iterations hasexceeded a threshold may be made in any suitable way. The determinationmay be made based on processing solely on the receiving device. Though,in some embodiments, processing on the transmitting device mayalternatively or additionally identify whether an error condition hasoccurred.

Any suitable processing may be performed in response to detecting anerror condition. In some embodiments, an error in receipt of a packetmay be indicated to a networking component, allowing the error to beaddressed at higher protocol levels. Also, as part of error processing,data structures associated with attempts to receive a packet may bereset. Those data structures may include packets store 172 (FIG. 1C).

The processing illustrated in blocks 640, 642, 644, 646, 650, 660 and670, may also be performed in response to a determination that, though areceived transmission attempt has passed CRC error checking, thereceived data is unreliable. Accordingly, FIG. 6 illustrates that upondetermination that data representing a received packet is unreliable,the process may branch from decision block 622 to decision block 630.

It should be appreciated that FIG. 6 illustrates just one possibleprocess that may be used on a receiving device. Some or all of theprocessing illustrated in FIG. 6 may be omitted or other variations maybe made. For example, the processing illustrated in FIG. 6 correspondsto an embodiment in which a protocol specifying that a NAK is sent whena transmission attempt is received but is not deemed sufficientlyreliable to provide data from the packet to a destination component. Inembodiments in which no NAK is sent, processing at block 632 may beomitted. Similarly, processing at block 630 may be omitted inembodiments in which a combined packet is formed by weightedcombinations of received transmission attempts. Weighting receivedtransmission attempts in proportion to their reliability may achieve thesame results as discarding received transmission attempts with very lowreliability. Also, it should be recognized that processing at block 644may not be present in embodiments in which received transmissionattempts are combined on a symbol by symbol basis.

FIG. 7 illustrates processing that may be performed on a transmittingdevice. The processing illustrated in FIG. 7 is performed in anembodiment in which a transmitting device and receiving devicecommunicate according to a protocol that does not require sending a NAKwhen a received transmission attempt does not allow reliabledetermination of the data in a packet. Though, it should be appreciatedthat similar processing may also be performed in an embodiment in whicha NAK is received. The processing described to occur when no ACK isreceived could alternatively or additionally occur in response toreceiving a NAK.

The processing of FIG. 7 illustrates transmission of a packet. Theprocessing of FIG. 7 may begin in response to generation of data to betransmitted in a packet. The data may be generated by an application orother components. Though, the source of data to be transmitted is not alimitation on the invention.

Regardless of the source of data, processing may begin at block 710where a CRC is performed on the data. The CRC value may be added to thedata to be transmitted.

At block 720, FEC code may be applied to the data, including theappended CRC value. At block 730, the data, as encoded using the FECcode and the CRC code, may then be transmitted. Though, in someembodiments, an initial transmission attempt may entail transmission ofonly a portion of the bits of a packet as encoded with an FEC code. Asis known in the art, encoding data with an FEC code results in redundantbits in the encoded data. Stronger codes have more redundant bits,allowing a larger number of errors to be corrected by a receivingdevice. If a strong FEC code is used to encode a packet, all of theredundant bits may be necessary to reliably receive the packet andcorrect for errors when channel conditions are favorable fortransmission.

In some embodiments in which a receiving device stores an unreliablereceived transmission attempt for use in constructing a reliablecombined packet, it may be possible to initially send a portion of theredundancy bits that could be generated by a strong FEC code. Ifadditional redundancy bits are required to reliably receive the packetbased on channel conditions at the time, a successive transmissionattempt may convey the additional redundancy bits. Accordingly, theinitial transmission attempt may be at a higher coding rate (fewerredundant bits) than can be generated by processing at block 720. Insome embodiments, the higher coding rate may be achieved by initiallygenerating all the redundancy bits associated with a packet, butstoring, without initially transmitting, a portion of those redundancybits. Though, in another embodiment, initial processing at block 720 mayentail encoding the packet at a first coding rate with processing atblock 720 for subsequent transmission attempts encoding the packet at asecond, lower, coding rate so that more redundant bits are available.Though, regardless of how and when the redundant bits are generated, inan initial attempt, the packet may be sent with only a subset of thepossible redundant bits.

At decision block 740, the process may branch, depending on whether anACK is received. If an ACK is received in response to the transmission,the packet may be deemed to have been reliably transmitted. Accordingly,the process may end when the ACK is received.

Conversely, if no ACK is received within an expected time, the processmay branch to block 750. At block 750, the encoding of the datarepresenting a transmission attempt may be modified for increasedreliability. In the embodiment illustrated, the modification may involveincreasing redundancy bits in a transmission attempt of the packet.Redundancy may be increased by decreasing the coding rate used at block720 or in any other suitable way. As an example of a possible variation,subsequent transmission attempts may involve, rather than retransmittingthe full packet, transmitting additional redundant bits. Regardless ofthe manner in which the additional redundant bits are communicated insubsequent transmission attempts for a packet, the receiving device mayuse the additional redundant bits to increase the likelihood that thepacket is received correctly.

As a specific example, in an embodiment in which a subsequenttransmission attempt entails only additional redundant bits thereceiving device may add the redundant bits to a previously receivedtransmission attempt stored in packet store 172. The receiving devicemay then attempt to decode that transmission attempt, including theadditional redundancy bits, using an FEC code with a lower encoding ratethat matches the total number of redundant bits in the initialtransmission attempt plus the additional redundant bits received in thesubsequent attempt. Depending on the reliability of the decoding, thattransmission attempt may be notified to the network stack or, if thereliability is still below a threshold, store the received transmissionattempt in packet store 172 to await a further transmission attempt.

As an alternative, if a retransmission attempt includes the full packetencoded with a lower coding rate, the receiving device may decode thetransmission attempt with an FEC having a lower coding rate and,depending on the reliability of the received transmission attempt,notify the packet to the network stack, combine it with previouslyreceived transmission attempts or store it for combining withsubsequently received transmission attempts. In this embodiment,processing may be performed in accordance with the method of FIG. 6,with the exception that FEC decoding at block 612 performed in differentiterations of the process may entail different strength FEC codes.

Regardless of how the additional redundant bits are reflected insubsequent iterations, the process may then loop back to block 710 wherea further transmission attempt is made. The process may continue in thisfashion until an ACK is received, indicating the packet has beenreliably transmitted. Though, a limitation may be imposed on the numberof iterations of the process of FIG. 7 that are performed or any othersuitable limitation may be applied. Also, a limitation may be imposed onthe number of iterations in which additional redundant bits aretransmitted. For example, the number of redundant bits may only beincreased for a limited number of iterations. As a specific example, thenumber of redundant bits may only be increased in the secondtransmission attempt. Subsequent transmission attempts may repeat thefull packet, including all the redundant bits previously transmitted.

Having thus described several aspects of at least one embodiment of thisinvention, it is to be appreciated that various alterations,modifications, and improvements will readily occur to those skilled inthe art.

For example, FIG. 4 illustrates that multiple data sets representingsuccessive received transmission attempts of a packet all have the samenumber of symbols. It should be appreciated that, because of errors,some transmission attempts will be received incomplete, with fewersymbols than others. Any suitable processing may be performed in thatcase. For example, received transmission attempts with fewer symbolsthan others may be discarded. Alternatively, a matching process may beused to align received symbols in different received transmissionattempts for comparison.

Such alterations, modifications, and improvements are intended to bepart of this disclosure, and are intended to be within the spirit andscope of the invention. Accordingly, the foregoing description anddrawings are by way of example only.

The above-described embodiments of the present invention can beimplemented in any of numerous ways. For example, the embodiments may beimplemented using hardware, software or a combination thereof. Whenimplemented in software, the software code can be executed on anysuitable processor or collection of processors, whether provided in asingle computer or distributed among multiple computers.

Also, it should be appreciated that FIGS. 1B and 1C illustratefunctional components. A computing device may be implemented with anysuitable partitioning of the components illustrated. As a specificexample, encoding segment 135 is shown separately from network stack 132and NIC 146. Though, it should be appreciated that encoding segment 135may be implemented in software and the functions of encoding segment 135may be implemented as part of network stack 132. Conversely, thefunctions of encoding segment 135 may be implemented in hardware as partof NIC 146. Though, other suitable partitions are possible. For example,some of the functions of encoding segment 135 may be implemented in adriver associated with NIC 146 or the functions of encoding segment 135may be split between network stack 132 and NIC 146. Similarly, thefunctions of decoding segment 153 may be performed within NIC 150, adriver for NIC 150 or within network stack 176, or may be distributedover these components in any suitable way.

Further, it should be appreciated that a computer may be embodied in anyof a number of forms, such as a rack-mounted computer, a desktopcomputer, a laptop computer, or a tablet computer. Additionally, acomputer may be embedded in a device not generally regarded as acomputer but with suitable processing capabilities, including a PersonalDigital Assistant (PDA), a smart phone or any other suitable portable orfixed electronic device.

Also, a computer may have one or more input and output devices. Thesedevices can be used, among other things, to present a user interface.Examples of output devices that can be used to provide a user interfaceinclude printers or display screens for visual presentation of outputand speakers or other sound generating devices for audible presentationof output. Examples of input devices that can be used for a userinterface include keyboards, and pointing devices, such as mice, touchpads, and digitizing tablets. As another example, a computer may receiveinput information through speech recognition or in other audible format.

Such computers may be interconnected by one or more networks in anysuitable form, including as a local area network or a wide area network,such as an enterprise network or the Internet. Such networks may bebased on any suitable technology and may operate according to anysuitable protocol and may include wireless networks, wired networks orfiber optic networks.

Also, the various methods or processes outlined herein may be coded assoftware that is executable on one or more processors that employ anyone of a variety of operating systems or platforms. Additionally, suchsoftware may be written using any of a number of suitable programminglanguages and/or programming or scripting tools, and also may becompiled as executable machine language code or intermediate code thatis executed on a framework or virtual machine.

In this respect, the invention may be embodied as a computer readablemedium (or multiple computer readable media) (e.g., a computer memory,one or more floppy discs, compact discs (CD), optical discs, digitalvideo disks (DVD), magnetic tapes, flash memories, circuitconfigurations in Field Programmable Gate Arrays or other semiconductordevices, or other non-transitory, tangible computer storage medium)encoded with one or more programs that, when executed on one or morecomputers or other processors, perform methods that implement thevarious embodiments of the invention discussed above. The computerreadable medium or media can be transportable, such that the program orprograms stored thereon can be loaded onto one or more differentcomputers or other processors to implement various aspects of thepresent invention as discussed above.

The terms “program” or “software” are used herein in a generic sense torefer to any type of computer code or set of computer-executableinstructions that can be employed to program a computer or otherprocessor to implement various aspects of the present invention asdiscussed above. Additionally, it should be appreciated that accordingto one aspect of this embodiment, one or more computer programs thatwhen executed perform methods of the present invention need not resideon a single computer or processor, but may be distributed in a modularfashion amongst a number of different computers or processors toimplement various aspects of the present invention.

Computer-executable instructions may be in many forms, such as programmodules, executed by one or more computers or other devices. Generally,program modules include routines, programs, objects, components, datastructures, etc. that perform particular tasks or implement particularabstract data types. Typically the functionality of the program modulesmay be combined or distributed as desired in various embodiments.

Also, data structures may be stored in computer-readable media in anysuitable form. For simplicity of illustration, data structures may beshown to have fields that are related through location in the datastructure. Such relationships may likewise be achieved by assigningstorage for the fields with locations in a computer-readable medium thatconveys relationship between the fields. However, any suitable mechanismmay be used to establish a relationship between information in fields ofa data structure, including through the use of pointers, tags or othermechanisms that establish relationship between data elements.

Various aspects of the present invention may be used alone, incombination, or in a variety of arrangements not specifically discussedin the embodiments described in the foregoing and is therefore notlimited in its application to the details and arrangement of componentsset forth in the foregoing description or illustrated in the drawings.For example, aspects described in one embodiment may be combined in anymanner with aspects described in other embodiments.

Also, the invention may be embodied as a method, of which an example hasbeen provided. The acts performed as part of the method may be orderedin any suitable way. Accordingly, embodiments may be constructed inwhich acts are performed in an order different than illustrated, whichmay include performing some acts simultaneously, even though shown assequential acts in illustrative embodiments.

Use of ordinal terms such as “first,” “second,” “third,” etc., in theclaims to modify a claim element does not by itself connote anypriority, precedence, or order of one claim element over another or thetemporal order in which acts of a method are performed, but are usedmerely as labels to distinguish one claim element having a certain namefrom another element having a same name (but for use of the ordinalterm) to distinguish the claim elements.

Also, the phraseology and terminology used herein is for the purpose ofdescription and should not be regarded as limiting. The use of“including,” “comprising,” or “having,” “containing,” “involving,” andvariations thereof herein, is meant to encompass the items listedthereafter and equivalents thereof as well as additional items.

What is claimed is:
 1. A method of operating a computing device toreceive data over a network, the method comprising: receiving a firstcopy of a packet via a network interface; performing error correction onthe as-received first copy of the packet; determining that the errorcorrected first copy of the packet includes at least one uncorrectederror; receiving a second copy of the packet via the network interface;performing error correction on the as-received second copy of thepacket; determining that the error corrected second copy of the packetincludes at least one uncorrected error; combining the error correctedfirst copy of the packet with the error corrected second copy of thepacket, the combination being based at least in part on a determinedreliability of symbols of the error corrected first copy of the packetand a determined reliability of symbols of the error corrected secondcopy of the packet; and providing an output packet based at least inpart on the combination of the error corrected first copy of the packetwith the error corrected second copy of the packet.
 2. The method ofclaim 1, wherein the second copy of the packet was encoded with an errorcorrection code of a higher strength than used for the first copy of thepacket.
 3. The method of claim 1, wherein: the determined reliability ofthe error corrected first copy of the packet is based on a probabilitythat the error corrected first copy of the packet includes anuncorrected error.
 4. The method of claim 1, wherein: the first copy ofthe packet was encoded with an error correction code and an errordetection code; and determining that the error corrected first copy ofthe packet includes at least one uncorrected error, includes: checkingthe error detection code after performing the error correction on theas-received first copy of the packet.
 5. The method of claim 4, wherein:performing the error correction on the as-received first copy of thepacket includes correcting the as-received first copy of the packet withthe error correction code.
 6. The method of claim 5, wherein: the methodfurther comprises maintaining in a store error corrected copies ofpackets that have been determined to include uncorrected errors.
 7. Themethod of claim 6, further comprising: resetting the store in responseto the providing of the output packet.
 8. The method of claim 1, furthercomprising: transmitting a NAK in response to the determination that theerror corrected first copy of the packet includes at least oneuncorrected error.
 9. A wireless receiving device, the devicecomprising: a wireless network interface that receives transmissionattempts of a packet; an error correction component that performs errorcorrection on received transmission attempts of the packet based onerror correction coding of the received transmission attempts of thepacket; an error checking component that determines reliability of errorcorrected transmission attempts of the packet based on error detectioncoding of the transmission attempts of the packet; and a packet analyzerthat combines at least two transmission attempts of the packet into anoutput packet based at least in part on the determined reliability forthe at least two transmission attempts of the packet and that providesthe output packet as a reconstruction of the packet.
 10. The wirelessreceiving device of claim 9, wherein the error detection coding iscyclic redundancy check (CRC) coding.
 11. The wireless receiving deviceof claim 10, wherein the error correction coding is forward errorcorrecting code (FEC) coding.
 12. The wireless receiving device of claim11, wherein: the error correction component also computes a degrees ofreliability for each of a plurality of symbols of received transmissionattempts of the packet; and the packet analyzer also forms the outputpacket by forming weighted combinations of symbols from a currentreceived transmission attempt of the packet and stored informationrepresenting at least one prior received transmission attempt of thepacket, the weighted combinations being formed based on the computeddegrees of reliability for the respective symbols of the currentreceived transmission attempt of the packet and the at least one priorreceived transmission attempt of the packet.
 13. The wireless receivingdevice of claim 9, wherein the wireless network interface sends a NAK inresponse to an error correction failure.
 14. The wireless receivingdevice of claim 9, wherein the error correction coding comprises innererror control coding and the error detection coding comprises outererror control coding.
 15. The wireless receiving device of claim 9,wherein the wireless network interface, the error correction component,the error detection component, and the packet analyzer comprise aunitary component.
 16. At least one computer storage medium comprisingcomputer-executable instructions that, in response to execution by aprocessor, perform operations comprising: receiving a copy of a packetvia a network interface; performing error correction on the as-receivedcopy of the packet; determining that the error corrected copy of thepacket includes at least one uncorrected error; combining the errorcorrected copy of the packet with a previously received copy of thepacket, the combination being based at least in part on determinedreliability for respective symbols of the error corrected copy of thepacket and of the previously received copy of the packet; and providingan output packet based at least in part on the combination.
 17. The atleast one computer storage medium of claim 16, wherein the received copyof the packet includes a greater number of redundancy bits than thepreviously received copy of the packet.
 18. The at least one computerstorage medium of claim 16, wherein the as-received copy of the packetis encoded with cyclic redundancy check (CRC) coding and forward errorcorrection (FEC) coding.
 19. The at least one computer storage medium ofclaim 16, wherein combining the error corrected copy of the packet withthe previously received copy of the packet includes: forming weightedcombinations of symbols from the as-received copy of the packet and fromthe previously received copy of the packet, the weighted combinationsbeing formed based on determined reliabilities of symbols of theas-received copy of the packet and of the previously received copy ofthe packet.
 20. The at least one computer storage medium of claim 16,wherein: symbols of the as-received copy of the packet and of thepreviously received copy of the packet are represented by values of atleast two signal properties, and combining the error corrected copy ofthe packet with the previously received copy of the packet comprisesaveraging each of the at least two signal properties for correspondingsymbols of the error corrected and previously received copies of thepacket.